You should be able to do this. Try using: + (void)restoreWindowWithIdentifier:(NSUserInterfaceItemIdentifier)identifier state:(NSCoder *)state completionHandler:(void (^)(NSWindow * _Nullable, NSError * _Nullable))completionHandler NS_SWIFT_UI_ACTOR API_AVAILABLE(macos(10.7)); https://developer.apple.com/documentation/appkit/nswindowrestoration/restorewindow(withidentifier:state:completionhandler:)?language=objc Appkit restores window frames automatic but if something funky is going on and that is being done too late you can ensure the window size is restored early by setting it yourself in +restoreWindowWithIdentifier:state:completionHandler: before you call the completionHandler.

I experience this issue every day, across many different apps, all the time on my iPhone SE 3rd gen. I've just been ignoring because I've been kind of busy with macOS. But really an annoying bug. Happens in Safari all the time. Usually after playing a video on YouTube. But it happens other times too. Seeing this thread was posted way back in September is kind of demoralizing I think.

Err so 304 is the design time height of the first row I have in Interface Builder. And for some reason NSTableView tries to force that as the line scroll from within -tile. All my other rows are not that big. I guess I can reorder the rows in the xib, or just keep calling super with my own value. Edit: Also changing "Row sizing style" from "Match Canvas" to "Custom" allows me to change the row height to whatever I want. NSTableView apparently forces the value of row height as the scrollView's lineScroll. Does it need to be reset in every -tile call? I'm not sure. But I'm implementing heightOfRowByItem: so just setting the row height in the xib is the way to set line scroll without actually changing the height of the rows (which are not all the same)

I was able to cook something up with constraints and computing the styles for the date formatter with an offscreen label, then taking the best fitting style and using it on the onscreen label. BUT I'm still a teeny bit nervous about all this because: Changing the date format style causes.. the stringValue of the NSTextField to change which can cause.. The text field to invalidate its intrinsic content size (sometimes I guess). I don't really know my bounding width until I'm in layout. It's easy to avoid infinite loops in my code but autolayout with its strict exceptions and rules, implicit layout invalidation etc., it is not so easy to guard against rules that are not well documented. B/C autolayout claims it is not legal to change layout in the middle of layout how can I change the date format safely during layout? I'm not hitting the exception anymore which is good but as an extra precaution I have my NSTextFIeld subclass override -invalidateIntrinsicContentSize and do nothing..because I don't want setStringValue: to invalidate the layout, I want to adjust the .stringValue to live within the layout I already have. I hope that makes sense. Please don't be so strict throwing exceptions in Autolayout! Layout bugs, overlapping views, etc are typically not fatal errors IMO. Sincerely, Macho

I'm working on rewriting a little piece of code in my app. I have a label that displays a date and adjusts the date format (growing and shrinking based on available width). I take measurements using -sizeToFit and also make sure I don't end up in an infinite loop. But I get: **The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window. ** On this particular label I'm not using constraints because in this case that would seem to add a lot more complexity and I turn off translatesAutoresizingMaskIntoConstraints. At least in UIKit, I don't recall ever having issues calling -sizeToFit in -layoutSubviews or -viewDidLayoutSubviews. I guess I'm going to have to modify my approach and take my measurements offscreen. Autolayout is cool but I think it is sometimes too strict.

Well when I first wrote this code (probably ~8 years ago or so), using the atomic flag with RTFD file wrapper would overwrite an existing file. Without the atomic flag, the operation would fail if the file exists but the existing file would remain (which is my desired behavior). At some point this changed and now not specifying the atomic flag, does not overwrite an existing file as I already mentioned but for some reason fails while also discarding the existing file. I cannot think of a situation where that behavior makes any sense or is useful other than to make it easy to write code that causes accidental data loss. If overwriting is always desired (atomic or not) then an existing file shouldn't ever be an error reason I don't think. I guess I'm grumpy about the behavior changing unannounced in a way that impacts the behavior of apps. If the plan is to keep it this way going forward I think a big bold note should be added to the documentation "if you try to save to a URL that already exists, the operation will fail and the file will disappear"). In any case I've modified my code to write to a temp file first, and then try to move it afterwards. I guess you could argue that this is a better design and I'd agree. Perhaps I should have always done it this but the way I had it wasn't "wrong" until the rug got pulled.

So it sounds like a long shot I guess but I filed FB22492490 anyway because I don't really understand the point of failing with NSFileWriteFileExistsError if the existing file isn't going to be protected. Also suggest in the FB that documentation should be added.

Ya the connection bubbles are gone in source files it seems. I wouldn't be terribly surprised if this was on purpose as a "optimization" / way to clean out source from Xcode to make room for ...er never mind. You can still connect outlets/actions by just writing the property in your interface: @property (nonatomic, weak) IBOutlet NSTextField *label; -(IBAction)methodName:(id)sender And then making the connection in Interface Builder from the Connections Inspector. I use to use the Assistant editor and make connections the way you describe all the time back in the day when I was learning UIKit but I do find it faster to just type the property with IBOutlet and then connecting it in the Connections Inspector in IB. A shame not to see those nice little connection bubbles anymore in source files. I don't care what anyone says about "live previews" or whatever...IB was the thing. It's a shame Apple doesn't make improvements to it anymore but I still find it useful.

OTOH, if you don’t set that flag then you’re telling the system that you don’t care about the state destination in the error case. The system is free to choose whatever writing techniques that it finds convenient. From the perspective of an app developer, it certainly is interesting for a save operation to fail with NSFileWriteFileExistsError while simultaneously deleting the existing file because the system finds it convenient! If you're going to chuck the file anyway is there really a point of failing after that? In any case this was a breaking change (it definitely wasn't always this way) and wasn't documented (as far as I know). But I guess my thread here helps serve that purpose and I was just "lucky" before. you’re writing to a temporary file Given how it works now, if you don't 100% know you own the path you have no choice but to write a temp since if an error occurs the system reserves the right to remove existing files at its convenience. That behavior probably should be documented IMO.

Looks like Apple or maybe another app on my system decided to remap the file extension to a different UTI, I'll have to dig further to find out. Whoever is responsible doesn't own the type (I don't own it either but I'm also not trying to hijack the file extension). in any case NSDocument/NSDocumentController doesn't appear to be responsible and is in the clear.

Thanks for sharing! They do the same thing in the Navigator now too I just noticed. I think the transition between a segmented control and a pop up button here is a little weird but overall not as bad as I initially thought. I'll just widen the navigator/inspector as needed.

Still in 26.4. It goes beep beep beep, like the horn on the bus!

Still running into this regularly. I think it may have something to do with using NSStatusBarButton. Is your app using NSStatusBarButton by any chance? Might be related to the timing of when I set the button's image. Really AutoLay is being overly aggressive IMO. I have another window in my app (besides what's created with from status bar button. And in the initializer are started returning nil (so only the status bar button would be created). And I still hit _NSDetectedLayoutRecursion. I don't think I have any other window created at this time but maybe I do.. I'll have to look deeper... think it has something to do with that button, though.

If an app assumes it's appending only one path component on a directory it owns (like inside a package), it may think it is safe, but it can be tricked into overwriting files at unexpected file system locations.

If you pass a string containing slashes where developers intentionally appended multiple components at once (e.g., [baseURL URLByAppendingPathComponent:@"Dir/Subdir/file.txt"]). Interesting. I did not realize this was intended. I would prefer an explicit -urlByAppendingPathComponents:(NSArray<NSString*>*) method for that use case. What is your concern about the API? I actually find that this API accepting this syntax /../../../ to walk parent directories rather terrifying. As many path components as you want? While that syntax has its uses I think it is extremely rare for developers to use -URLByAppendingPathComponent: intentionally in that way with that purpose in mind. The name of the method implies one I think? And you are most often trying to go forward not backward when you use this API. Tell Xcode where my headers are use of @".." okay fine but most apps don't do that. IMO that should probably be split into a different API that clearly describes the purpose. To walk back parent directories the more sane thing to do, in most apps I think is to use URLByDeletingLastPathComponent instead. If it isn't considered a 'security issue' on its own it at least looks like the seed of one.